Active functionality is supported in database systems by adding ECA (event-condition-action) rules, in which an action occurs in response to an event and is executed after the rule is triggered and the condition is evaluated true.
Commercial database systems provided by corporations such as International Business Machines Corporation, and Oracle Corporation incorporate limited active functionality by defining triggers on database tables. Simple ECA rules based on primitive database events can be mapped to triggers. These triggers provide a further facility to evaluate conditions relating to the data associated with the event within the code for the trigger. An example of such a database event is “when a employee from HR department leaves his job”.
Temporal conditions can also be associated with database events. An example of such an event is “if an error is reported on a weekend”. Such events are detected in existing systems by defining a trigger, and checking the time of occurrence of the event using a User Defined Function (UDF), or by any other suitable mechanism implemented in the trigger code. The time of occurrence of the event can also be checked outside the trigger code by notifying an external entity, using a messaging system or some other means.
Triggers that have temporal conditions reside permanently on the application database, and these trigger conditions are checked for every transaction. The trigger fires, however, only when the temporal condition is met.
Commercial databases provide means for disabling triggers for a particular user. Triggers can also be disabled temporarily by defining a trigger lookup table_state, which maintains a list of triggers by name and their status (active=“Y” for yes, or “N” for no). The disabling or enabling of triggers is performed manually. That is, some systems change the data in the lookup table.
All of these techniques require that the triggers to be permanently present on the application database, unless the triggers are manually removed from the database. Increasing the number of triggers defined on the system degrades the performance of the system, as triggers affect database performance.
Rules may be triggered when there is new data in the working memory that matches the pattern defined in the rule. The HiPAC project [U. Dayal, B. Blaustein, A. Buchmann, U. Chakravarthy, M. Hsu, R. Ledin, D. McCarthy, A. Rosenthal, S. Sarin, M. J. Carey, M. Livny, R. Jauhari “The HiPAC Project: Combining Active Database and Timing Constraints”, ACM SIGMOD Record, vol 17, no 1, pp 51-70, 1988] allows by far the most complex triggering events (including database, transaction and temporal events) of any database rule language. The HiPAC project is apparently the first system to demonstrate active functionality in databases, but many of its proposed features have not been implemented in commercial database systems.
This and other existing systems require triggers to be permanently present and active on application databases, which hampers system performance. A need clearly exists, in view of the observations made herein, to provide a database system that addresses limitations associated with existing techniques for using triggers in database systems.